Profile picture

[Kerdy] 5차 데모데이 회고

Amaranth2023년 10월 07일

서론


우테코 레벨 3 끝 자락에 Kerdy 서비스의 정식 버전을 구글 플레이스토어에 출시한 뒤 한달이라는 시간이 지났습니다.

지난 9월 22일에 5차 데모데이를 진행했는데요, 레벨 4를 시작하고 한 달 동안 프로젝트와 관련해 어떤 일을 했는지를 발표하는 시간이었습니다.

그 때 우리 팀이 발표한 내용을 글로 다시 한 번 정리해보려 합니다.

본론


저희는 지난 한 달간 크게 1. 사용자 끌어모으기, 2. 서비스 성능을 개선하기의 2가지 목표를 잡고, 이 목표를 달성하기 위해 다음과 같은 작업을 했습니다.

1. 5차 데모데이 요구사항 달성

백엔드 팀원들에게 할당된 5차 데모데이 요구사항은 다음과 같았습니다.

  • Thread 관련 설정

저희는 적정한 스레드 설정 값들을 찾기 위해 부하테스트를 진행했습니다.

부하테스트 환경으로 개발 서버를 사용했는데, 실제 프로덕션 서버와 유사한 환경에서의 결과를 확인하고 싶었기 때문입니다.

부하테스트 툴로는 학습 곡선이 낮은 Jmeter를 선택했습니다.

부하테스트 시나리오는 다음과 같았습니다.

[!NOTE] 시나리오 60초 동안 400명의 유저가 매 초 1번씩 행사 목록 조회 API를 요청한다.

행사 목록 조회 API를 선택한 이유는 서버에 가장 많은 부하를 주고, 또 사용자들이 가장 많이 사용될 것으로 예상되는 API였기 때문입니다. 여기서, 실제 상황처럼 구성하기 위해 API의 쿼리 스트링을 랜덤으로 할당되도록 설정해 주었습니다.

이러한 시나리오를 바탕으로 몇 가지 케이스를 분류해 부하테스트를 했고, 케이스 별로 지연율, TPS, CPU 사용량, 메모리 사용량 통계를 기록했습니다. 그 결과 위와 같은 결과가 나왔고, Spring의 Default 설정이 제일 낫다 판단하여 그렇게 설정해주었습니다.

  • 쿼리 최적화

쿼리 최적화 작업을 하기 앞서, API에 대해 N+1 문제 발생 여부를 판단할 수 있는 수단이 있으면 좋겠다는 의견이 나왔고 저희 팀은 AOP를 활용해 API 별 쿼리 호출 횟수를 계산하는 N+1 Detector를 제작하였습니다. 이후 Fetch Join을 사용해서 N+1 문제를 해결하는 작업을 진행했습니다.

다음 이미지는 그 중 가장 유의미한 변화를 보인 쿼리문을 캡쳐한 것입니다. 무려 API를 한 번 호출할 때마다 229개의 쿼리가 나가던 것이 Fetch Join 처리 이후 9개의 쿼리만 나가도록 개선되었습니다.

그 다음으로는 인덱스를 활용해 최적화를 진행했는데요, 모든 조회 쿼리에 인덱스를 적용하는 것은 오히려 독이라고 생각해, 알림(Notification)과 같이 레코드 양이 많은 테이블에만 인덱스를 적용해주었습니다.

2. 사용자 피드백 반영

사용자를 끌어모으기 위해 가장 중요한 것은 사용자의 실질 피드백을 반영하는 것이라고 생각했습니다.

그래서 저희 팀이 가장 먼저 한 일은 Kerdy 서비스를 이용한 사용자로부터 피드백을 수집하는 것이었습니다.

우테코 론칭 페스티벌에서 얻은 피드백과 주변 지인들에게 직접 서비스를 홍보하면서, 저희 팀은 하나 둘씩 사용자 피드백을 모을 수 있었습니다.

이후 팀 회의를 거쳐 그 중 몇 가지를 저희 서비스에 반영하기로 결정했고, 결과적으로 다음의 3가지 기능을 추가적으로 구현하게 되었습니다.

  1. 행사 정보에 온/오프라인, 유/무료 여부 태그 추가

    피드백을 보니 온/오프라인 여부와 유/무료 여부는 행사 정보를 찾는 사용자들이 중요하게 보는 요소였습니다.

    지방에 거주하는 학생이었던 저 역시 온라인 행사를 위주로 행사를 찾곤 했기 때문에 크게 공감되었던 피드백이었습니다.(대부분의 행사는 서울에서 주최되기 때문)

  2. 사진을 추가할 수 있는 피드 기능 추가

    기존에는 행사에 댓글을 달 수 있었는데, 댓글 대신에 이미지를 첨부할 수 있는 피드를 도입하자는 의견이었습니다.

    커뮤니티성 컨텐츠이기 때문에 사진을 올리고 싶어하는 사용자가 많을 거라고 생각해 반영하게 되었습니다.

  3. 서비스 자체적인 쪽지 기능 추가

    매칭된 사용자들 간에 소통이 필요한 경우, 기존에 구현했던 방식은 사용자가 직접 등록해둔 카카오 오픈 프로필 링크를 통해 채팅을 연결해주는 식이었습니다.

    하지만 론칭 페스티벌 당시, 저희의 서비스를 체험해본 크루 대부분이 카카오 오픈 프로필을 등록하는 과정에서 헤매는 모습을 보고 이 방식은 사용성이 떨어진다는 사실을 알게 되었습니다. 뿐만아니라 외부 서비스에 의존하는 것은 서비스를 불완전하게 만들기 때문에, 저희는 독립적인 소통 시스템이 필요하다 판단하여 쪽지 기능을 도입하게 되었습니다.

3. 추가 기능 구현

사용자 피드백 수용에서 이어지는 내용입니다.

  1. 피드 추가

    기존의 댓글은 없애지 않고 피드에 달 수 있도록 해 수정 범위가 커지지는 않았습니다. 이미지를 관리할 필요성이 생겨 S3를 도입하고 이미지 처리 메커니즘과 구현 방식에 대해 고민하였습니다.

  2. 관리자 페이지 제작

    Kerdy 서비스의 특성 상, 사용자에게 직접적으로 보여지는 행사 데이터를 추가하고 관리하는 작업이 매우 중요했습니다. 주기적으로 새로운 데이터를 입력하고, 수정하고, 확인할 수 있어야 했죠. API는 만들어져 있었지만 일일이 데이터를 넣어주어야 했기에 실수하기 쉬웠고 불편했습니다.

    그래서 팀원들 모두가 좀 더 편리하게 데이터를 관리할 수 있는 환경의 필요성을 느꼈고 이러한 요구사항에 따라 저희 팀은 새로 관리자페이지를 만들었습니다. 지난 한 달간은 API 호출과 사용자(관리자)의 편의를 위한 UX적인 기능을 구현하는 데 집중했고, 남은 한 달동안은 잠재적인 보안 문제를 고려해 접근성을 개선하는 작업을 해나갈 계획입니다.

4. 백엔드/안드로이드 간 협업

피드 기능을 구현하는 과정에서 백엔드와 안드로이드 간 협업을 경험했습니다. 함께 이미지 처리 메커니즘에 대해 고민하였습니다.

5. 사용자 유치 전략 세우기

앞으로 목표치인 실사용자 66명을 달성하기 위해 고안한 사용자 유치 전략은 다음과 같습니다.

  1. 홍보

    • 커뮤니티(에타, 동아리, 오픈 채팅방 등 IT 관련 탭)에 홍보
    • 컨퍼런스를 직접 방문해서 네트워킹 시간에 홍보 활동
    • 홍보를 위한 공동 인스타그램 계정 운영

  2. 피드백 수집

    • 사용자에게 직접 쪽지를 보내 1:1 피드백 요청
    • 구글 폼을 이용하여 사용자 피드백 받기
    • 오픈 채팅방에서는 직접 피드백 받기
    • Google PlayStore 이용자 리뷰 수집

결론


하나의 프로젝트를 완성하고, 나아가 어떻게 하면 프로젝트를 보다 개선하고 사용자들을 끌어모을 수 있을지 고민할 수 있어 뜻깊은 시간이었습니다.

이렇게 정리해보니 한 달간 이루어낸 일이 굉장히 많은 것 같습니다. 이게 다 팀원들의 노력 덕분이라고 생각해요. 프로젝트를 통해 얻은 경험들이 정말 소중하게 느껴집니다.

남은 한 달도 Kerdy 서비스에 많은 기여를 할 수 있도록 노력해봐야겠습니다.


Loading script...